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(54) Improved equity access system 

(57) Data processing for an improved equity access and management account flexibly permits owner access to a 
line of credit. The line of credit mav typically be secured, as by the equity in a client's jomeorother asset . Charges 
agaios tthe^je at accQunt may be of yarying^tarins, e.g., by cnequet ciiarqe cafd'tfr casF advance , and decrement 
available credit remaining in the credit line wherTauthonzed. Account loan principle is increased when charges are 
incurred, and reduced upon full or partial payment;. Charges for interest, late fees and the like, sometimes 
differing in rate or amount based upon an independent variable such as security situs, are assessed against client 
accounts, and account status and balances are periodially reported. 
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SPECIFICATION 

Improved equity access system 

Disclosure of the Invention 

This invention relates to financial business systems and, more specifically, to an improved data 
5 processing arrangement for permitting and administering a flow of charges and credits against a pre- 5 
established, typically secured line of credit. 

It is an object of the present invention to provide an improved equity access acount 
IVIore specifically, it is an object of the present invention to provide a data processing 
implementation for an equity access and management system which flexibly permits and accounts for 
1 0 client access to and charges and credits against a pre-established line of credit via checks, charge cards 1 0 
and the Nice. 

The above and other objects of the present invention are realized in a specific, illustrative data 
processing arrangement for an improved equity access and management account which flexibly permits 
owner access to a llnejalcredll . T he line of credit may typically be secured, as by the equity in a clien t's 
15 h ome or other asset. C harges against the client account may be of-varyinfl forms! e,g.r by check, charge 15 
c ard or ca^h advance, and decrement availa ble credit remajningjnjthecredit N en j^ujth orized . 
Account loan principle value Is increased when charges are incurred, and reduced upon full or partial 
payment. Charges for Interest, late fees and the like, sometimes differing In rate or amount based upon 
one or more independent variables such as security situs state, are assessed against client accounts; 
20 and account status and balances are periodically reported. 20 
The foregoing and additional features and advantages of the instant invention will become more 
readily apparent from the following detailed description of a specific, illustrative embodiment thereof, 
presented hereinbelow in conjunction with the accompanying drawings in which: 

Fig. 1 is a flow chart depicting data processing for authorization requests for the equity access 
25 accounts of the instant invention; 25 
Fig. 2 depicts in flow chart form post-transaction processing for the instant equity access-type 
accounts; and 

Fig. 3 is a schematic flow chart depicting periodic account processing and reporting in accordance 
with the principles of the present invention for an improved equity access system of accounts. 

30 Beginning first in overview, the equity access methodology and apparatus of the instant invention 30 
illustratively relate to client or customer accounts where each customer is permitted to incur charges 
against a pre-determined line of credit The credit line will typically be supported by a security interest in 
the client's equity in some underiying asset. As one example, the line of credit may be secured by a 
perfected, possibly subordinated lien on the client's home or other real property. The credit limit thus 

35 represents a fraction within pre-determined norms of the client's equity in the underlying asset 35 
remaining after more senior Tiens are taken into account, 
-szcs:^ Each client is given access to his/her pre-established line of cr edLt.b y a clientH mplem<^^ 

of anNMcn owoiilad, cred it cards,jcash .advances, or the like,.. In practice, each client 

establishes a line of credit with the system proprietor — and has his/her equity interest in the collateral 

40 form the subject of a recorded mortgage or the like. Once the security interest is perfected, the client 40 
may draw down against the pre-established credit limit by writing checks, making charges, or the like in 
amounts and at times of the client's own choosing without need for obtaining separate "loans" or fund 
releases. 

^ — The credit available to each individual will, of course, be reduced as the gross amounts of prior 
45 charges or take downs increases. Similarly, repayment of principle by subscribers pro tonto increases 45 
their available credit. 

At periodic times, the system operator makes various charges against each subscriber. Most 
obviously, the operator renders an interest charge based upon the time use of the outstanding loan 
principle balance from time to time. Other charges may also be made depending upon user/system 

50 options, e.g., late charges for belated payments, life insurance charges to forgive indebtedness upon 50 
demise of a system client, or the like. The basis of the several charges, e.g., interest, may be uniform (as 
some increment over the prime or federal funds rate applicable to all). Alternatively, such charges may 
depend upon independent variables, e.g., the state in which the underiying asset Is located to 
accommodateJocal usury, late charge limitation or other laws, regulations or practices. Obviously, other 

55 dependencies may obtain as well for other system operator services. Also at like or other periodic times, 55 
the system operator provides reports to individual clients, identifying such parameters as outstanding 
loan balance and subscriber charges for interest and insurance premiums. 

Accordingly, an equity access system as above outlined in essence permits a client to have 
unilateral access to the equity value iii his/her underlying property, i.e., to flexibly make expenditures or 

50 incur debt collateralized by equity in what is often an unliquid asset. Subject to contractual obligations, 60 
the subscriber may repay when and in such amounts as he/she chooses, thus providing great financial 
flexibility. 

Discussion will now be had with respect t the implementation of the above-described equity 
access system by the arrangement of the instant invention. In accordance with such processing, several 
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schematic programming variables are utilized. The variables bearing running index "1" are nap r- 
client basis, i.e., represent the subject parameter for the i-th client of the system. The more substantial 
of the vanables employed are as follows: 



10 



15 



20 



25 



30 



35 



40 



Variable Subject Matter Designated 

CRDAV(I) The credit available to a particular (i.e., to the "i-th") client remaining 5 

from his/her initially available credit line. 

TD(I) The take down or net charges (after any repayments) incurred to date for 

a particular client which may be conceptually viewed as the principle 
or loan balance of that customer at any point in time. 

TFEES(I) The system fees or charges to a particular customer, principally consisting 1 0 

of interest and late fees, if any. 

ADMD(l) The amount of a particular request for a charge authorization from a 

client such as the authorization to incur a credit card charge. 

MDMD(I) The amount of an actual monetary charge, credit or payment for a 

particular customer. 1 5 

f INT(I) The total interest incurred by a client during a portion of the processing 

for an accounting interval, e.g., a portion of a month for a static (constant) 
outstanding principle balance. 

INSP(l) Insurance premium for a customer during such a static (constant 

condition) period of a periodic accounting cycle. 20 

D The number of days for a periodic accounting interval of static or 

common account take down conditions. 

TRANS(J) A posted transaction, reflective of a prior monetary expenditure (that 

is, a previously encountered MDMD(I) transaction) from an array of 
possible such transactions for a customer. 25 

TRANS An interim processing variable to keep a running total of transactions 

TRAUS(J) over a processing interval. 

RT The operative daily Interest rate to be charged. 

RT(DY,S) The daily interest rate (doubly Indexed) for the day of year given by 

DY and state where the real property security is located (5). 30 

RTN The interest rate which obtains for the next accounting cycle day, 

i.e., the day following the date of RT. 

RT((DY+ 1 ),S) An interest rate from the double indexed interest rate table which follows 
by one day the rate of RT(DY,S). 

LTC(S) The rate charge from a scaler array which varies with the state situs 35 

(S) of the underiying real property asset. 

ITFE(l) The amount of fees charged by the system operator — as for interest, 

and which are due and unpaid at the beginning of a subject period, e.g., 
at the beginning of an accounting month. 

RSTd) Any limit restraints on authorizing new charges for a client — such as a 40 

credit card previously reported lost, or a check stopped for any reason. 

PRT Daily insurance premium rate per unit quantity f outstanding loan 

principle TD(I). 



RPY 



Value f principle TD(i) repayment being made by a system client. 



12/10/2002, EAST Version: 1.03.0002 



3 



GB 2 135 484 A 3 



With the above variables in mind, the processing of th system arrangement of the instant 
invention will now be specifically considered. Variable designations and computer processing steps ar 
schematic and illustrative only; and may be implemented in any coding language in any computing 
equipment. Turning first to Fig. 1 , there is shown a flow chart depicting the way authorization requests 
5 for the instant an-angement are processed. That is, the Fig. 1 flow chart generates an affirmative 5 
response (output message from block 21 ) or a negative response (output message from functional block 
1 8) when a client attempts to implement a charge, e.g., attempts to make a purchase with a charge 
card, write a check or make any other form of expenditure request The amount ADMD(I) for which 
credit is desired is entered into the system (block 1 2) and the credit remaining available to that client 

1 0 CRDAV(I) is read in from memory — step 1 3. Also recovered as a processing variable is any restraint 1 0 
(RST(I)) on credit for that customer, e.g., a lost credit card, check stop order or the like. Test 1 5 
examines the restraint data field for that client (RST(I)) for a flag bit signalling that no charge for the 
subject item is to be permitted. Most simply, the restraint data field may be a limited array of binary 
"1 's" and "O's" where for example each "0" bit permits a transaction of an associated kind whereas g 

1 5 "1 " bit does not. If the restraint flag bit stops the transaction (YES output of test 1 5), block 18 15 
generates an output message by signal light, teletype or the like which indicates that the requested 
authorization is not to be granted, and thus the transaction does not proceed. 

In the usual case, the transaction will not be blocked (N0 output of test 1 5) and a test 1 7 next 
determines whether the credit available to the subject i-th client is sufficient to accommodate the 

20 authorization inquiry then being processed, as by the inequality, 20 

CRDAV(I) > ADIVID(I) (1) 



if there is insufficient credit available (N0 output of test 1 7) a negative output message is produced by 
block 1 8; no further processing of the transaction occurs; and system processing flow returns to the 
START block 1 0 to await a next request. 
25 Assuming that sufficient credit is available, i.e., that the inequality ( 1 ) above is satisfied, the 
available credit remaining to the client is decremented by the amount ADMD(I) of the expenditure for 
which authorization is sought (block 20), as by, 

CRDAV(I) = CRDAV(I) - ADMD(I). (2) 



Step 2 1 generates an affirmative response to the authorization request in any desired form, e.g., as 
30 before by illuminating an "APPROVED" light, printing an output message, or the like. 30 
Approval/disapproval for a check item will cause the check to be paid (and the system operator^ s 
account at the payor bank to be debited) for the ADMD(I) account, or to be returned. A charge card 
request will permit the underlying charge transaction to proceed or to terminate — at least on a credit 
basis. 

35 The fact of the affirmative authorization command ADMD(I) is placed in the client's file to maintain 35 
a client table of approved authorization requests (block 25). System control then returns to the START 
block 1 0 to await any subsequent authorisation for any system client. 

The above processing thus either approves or disapproves an attempted client expenditure. When 
approved, the credit availability to the client (the contents of the storage address/processing variable 

40 CRDAV(I)) is decremented by the amount of the approved expenditure and a record of the authorization 40 
is maintained in the client file of all approvals. The pending authorizations are purged when matched 
with a completed transaction (MDMD(I)) processing discussed regarding Fig. 2 or after a period of time 
elapses to clear authorizations which never in fact resulted in expenditures — as when a retail customer 
obtained charge card approval but ultimately decided against a purchase. 

45 Turning now to Fig. 2, there is shown data processing for accounting for expenses after they have 45 
in fact occurred, beginning with a conceptual START point 30. As a first matter (step 38), the subject 
monetary expenditure (MDIVID(I)) is entered Into the system. It is noted that IVIDMD(I) is normally 
positive, representing a monetary disbursement or expenditure such as a check or charge. The MDMDd) 
variable is made negative for a client credit (e.g., a merchandise retum for a credit card purchase in a 

50 retail charge situation, or a client check to make a fee or principle (or both) repayment). Fig. 2 50 
processing in step 40 fetches from memory the total take down, i.e., the prior principle balance TD(I) of 
the customer, as well as his/her available credit variable CRDAV(I). 

Test 42 determines whether or not the item MDMD(I) being processed is a principle payment. To 
constitute a principle payment, the item must be a negative exp nse, i.e., a credit, which may be 

55 determined by MDMD(I) < 0 (YES output of test 42). When this obtains test 43 determines wheth r or 55 
not the absolute value of the payment MDIVIDd) exceeds the amount of the free TREES(I) which the 
customer owes. If not, the amount is simply credited against fees (step 46) and control returns to the 
start block 1 0 to begin processing anew. 

If, however, the amount of the payment exceeds the fees, the fee amount TREES(I) is set to "0" 

60 (step 44) and the remainder RPY computed as the difference b tween the credit (th negativ valu of 60 
MDMD(I)) and the fee amount. This differential then reduces the outstanding loan valu (step 48). 
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The next following step 50 reduces the credit availability of the customer by the amount RPY of 
repaid principle. This reduction (shown with an asterisk In step 50) is for a limited time only to prevent a 
b unced check r kiting situation. Thus, a fixed time later, e.g., seven days after principle repayment, , 
credit availability is restored by the amount RPY. Following execution of the principle reduction steps 48 
5 and 50, processing flows to step 60 to post the updated take down and available credit variables in 5 
computer memory following which system control returns to the starting point to process the next 
transaction. 

Assume now the normal case where the transaction being processed is an actual charge and not a 
principle repayment (N0 output of test 42). The next following operation 55 decrements the credit 
10 available to the customer (CRDAV(I)) by the amount of the charge MDMDd). Similarly, step 58 increases 1 0 
the amount of the client take down (TD(I)) by the amount of the charge MDMD{I). Following step 58, the 
updated circuit availability and client take down variables CRDAVd) and TD(I) are stored in memory, i.e., 
posted in the memory file and system control returns to its starting point to process the next item. 
Accordingly, Fig. 2 operation accommodates each executed monetary transaction, adjusting the 
1 5 appropriate customer's available credit and principle balance. 1 5 

Finally, referring to Fig. 3, there is shown in schematic form a flow chart of periodic, e.g., monthly 
processing to update the subscriber accounts and to generate the data required for subscriber billing 
and billing statements. As a first matter for each particular subscriber functional block 72 initializes 
processing variables. The D parameter (number of days for constant loan balance TD(t)) is initialized to 
20 "1 indicating that the next iteration through the subscriber functional loop will be the first for a fixed, 20 
constant set of conditions. The insurance INSP(I), interest TINT(I) and running transactions sum TRANS 
variables are each initialized to "0". Block 75 sets the prevailing daily interest rate parameter RT to the 
appropriate value from a doubly indexed look-up table corresponding to the state where the real 
property security is located and the day of year value specified by S and DY. Day of year may be derived 
25 from an internal computer calendar and the state identity S is identified as by an information block 25 
corresponding to the i-th subscriber whose data is then being processed. Thus, the value of RT is the 
daily interest rate appropriate for a particular day for the customer then being processed. The 
computation value RTN is comparable to the RT parameter, but is the rate obtaining for the next day, 
and is used for limited comparison purposes below discussed. Block 77 extracts from the data file the 
30 transactions for the day of the year (DY) being considered (for the i-th client) by the subject initial 30 
interaction through the Fig. 3 upper loop. 

Test 82 first determines whether or not a late fee must be charged, i.e., determines whether or not 
there has been a credit for processing for the i-th customer which has equaled or exceeded the total 
fees due at the beginning of the month as stored in ITFE(I). if a late charge is appropriate (YES output of 
35 test 82), the amount of fees TFEES(I) due from the client is incremented by the appropriate amount 35 
given by the product of the state-dependent late charge rate LTD(S) multiplied by the amount due at the 
beginning of the month ITFE(I) (block 85). If no late charge is incun-ed, as when the custonier had paid 
the ITFE(I) amount prior to the assumed late fee date, a N0 output obtains for test 82 and in either event 
processing then flows to functional block 90. 
40 In block 90, the running variable TRANS which accumulates the amount of transactional 40 
expenditures, is incremented by the day's transactions (if any) and test 93 determines whether or not 
there has been any change for interest billing purposes. More specifically, the amount of interest charge 
for the next day will change if either the prevailing interest rate RT changes (RTN ^ RT), or if the amount 
upon which interest is charged has changed which will occur if there have been any transactions. If 
45 neither of these change events occurs (YES output of test 93), the interest for the following day will be 45 
the same as the computer iteration previously processed since both the interest and principle balance 
are the same. Under these circumstances, block 96 increments by one the number of days (D variable) 
for which like or static principal balance and rate conditions obtain (corresponding to the number of 
iterations through the Fig. 3 common condition upper processing loop). Control then passes back to the 
50 block75 to begin the next day processing. 50 
Where, however, there has been a change (N0 output of test 93) control passes to the block 102 
and subsequent operations. This processing branch is invoked when it is no longer possible to simply 
update interest for one more day with alt other conditions remaining fixed. 

As a first matter, the functional block 1 02 computes the insurance for the subject client by the 
55 product of his outstanding loan balance multiplied by the premium rate (PRT) and the number of days 55 
(D) for the common customer condition processing. This may be done as by, 

INSP(I)=:TD(I)*PRT«D. (3) 

Functional bl ck 1 02 also increments the subscriber's total take down or principl balance by the 
am unt of the charged transactions (TRANS) and insurance premiums (under most state law, a proper 
60 loan principal item), 

TD(I) = TD(I) + TRANS + INSP(I). (4) 
The inter st contribution for the previous common processing interval (step 1 05) is next updated by 
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determining the product of the loan balance {TD(I)) times the rate obtaining (RT) times the numb r of 
days over which processing is being run as stored in the variable D, 

TliMT(l)=TD(l)*RT*D. 15) 

Similarly, the fee variable TFEES(I) for the customer is updated (step 1 06), by this newly computed 
5 interest Income, 5 

TFEES{l)=TFEESli)+TINT(l), (6) 

The computational variables for the number of days or iterations of the loop for static conditions (D), the 
interest rate obtaining (RT), the total Interest over the interval TINT(I) and the loan balance at the end of 
the interval (TD(I)) are then supplied as computational outputs (step 109). These variables are stored in 

1 0 memory and also provided as outputs as part of a reporting line over the time interval, i.e., over the D- 1 0 
days either directly or, if desired, following all processing for the subscriber or all processing over the 
monthly or other accounting interval. 

Test 1 1 0 determines whether or not all processing is finished for the t-th customer which is simply 
a matter of determining that the appropriate number of days in the month have been cycled through so 

1 5 that all transactions and charges for the customer are completed. If the customer processing is not 1 5 
completed (N(5 output of test 1 1 0), processing returns to the block 72 to begin the above discussed 
iterative operation anew. When the processing resumes, the running variables D, INSP(I), TliSITd) and 
TRANS are re-initialized as above discussed to begin computation for the next day or series of days if 
common conditions prevail. This operation continues until account processing for the customer is 

20 completed, that is, until the account is processed for each day of the reporting period. Following this, (a 20 
YES output of test 1 1 0) control passes to a test 1 1 3. Test 1 1 3 returns system functioning to the 
beginning of blocic 72 to initiate woric for the next (i + 1 st) customer (as by simply incrementing the 
indexing variable I) until all customer accounts have been processed at which point the resulting YES 
output of test 1 1 3 directs processing to a FINISHED point 1 1 5 to begin the next computer task. 

25 The above arrangement has thus been shown to process all of the system transactions over any 25 
desired periodic interval; to update all requisite variables during such processing, including the 
computer system charges for insurance, interest and the like; and to generate the parameters necessary 
for meaningful and complete output information for client reports. Moreover, the entire system as 
depicted in Figs. 1 — 3 provides a complete, flexible and integrated basis for access by an array of 

30 system clients to their loanable equity in an underiying asset or assets, and to unilaterally permit 30 
exercise of discretion to incur obligations against that credit on a demand basis in a variety of demand 
implementing forms. 

The above-described arrangement is merely illustrative of the principles of the present invention. 
Numerous modifications and adaptations thereof wilt be readily apparent to those skilled in the art 
35 without departing from the spirit and scope of the present invention. 35 

CLAIMS 

1 . In combination in a system for processing and supervising a plurality of client equity access 
accounts each permitting client credit line charges via client-implemented charge means, credit 
authorization means responsive to client instituted charges for determining and for signalling whether 

40 the client's remaining credit availability is sufficient to accommodate the charge requested, credit 40 
availability storage means and loan balance storage means for each client account, executed 
transaction means for processing transactions authorized by said authorization means for decrementing 
the contents of said credit availability storage means and for incrementing the contents of said loan 
balance storage means, and account processing means for assessing interest charges responsive to the 

45 contents of said loan balance storage n^ans, said credit authorization means comprising means for 45 
storing account restraint information, comparison means for comparing the amount for which 
authorization is requested with the amount stored for the requestor in said credit availability storage 
means, and means responsive to said comparison means and to the stored contents of said account 
restraining storing means for selectively providing an output authorization message. 

50 2. In combination in a system for processing and supervising a plurality of client equity access 50 
accounts each permitting client credit line charges via client-implemented charge means, credit 
authorization means responsive to client instituted charges for determining and for signalling whether 
the client's remaining credit availability Is sufficient to accommodate the charge requested, credit 
availability storage means and I an balance storage means f r each client account executed transaction 

55 means for processing transactions authorized by said authorization means f r decrementing the 55 
contents of said credit availability storage means and for incr menting the contents of said loan balance 
storage means, and account pr cessing means f r assessing interest charges responsiv to the contents 
of said loan balance storage means, wherein said executed transaction means includes m ans for 
differentiating charges and principl r payments, and repayment processing means responsive to an 

60 interest repayment by decrementing the contents of said loan balance storage means. 60 
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3. A combination as in claim 2 wherein said repayment proc ssing means includes means for 
decrementing said credit availability storage means, and m ans for restoring said credit availability 
storage means aft r a predetermined p riod of time. 

4. A combinati n as in claims 2 or 3, wherein said executed transaction pr cessing means further 

5 includes means for incrementing said loan balance storage means and for decrementing said credit 5 
availability storage means responsive to a differentiated charge item. 

5. A combination as in claims 2, 3 or 4, wherein said credit authorization means comprises means 
for storing account restraint information, comparison means for comparing the amount for which 
authorization is requested with the amount stored for the requestor in said credit availability storage 

1 0 means, and means responsive to said comparison means and to the stored contents of said account 1 0 
restraining storing means for selectively providing an output authorization message. 

6. A combination as in claim 1 or 2 wherein said client/implemented charge means includes 
checking means and credit card means. 

7. A processing system substantially as herein described with reference to and as illustrated in the 

15 accompanying drawings. 15 
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